We are given a specification for a persistence kernel designed for a 1950s-era machine with magnetic drums and tapes. The goal is to understand the provided seed routines and layout, and to note that this is the minimal executable persistence kernel.

The system has two mirrored drums (DRUM_A and DRUM_B) with a fixed layout:

• Tracks 0-9: WAL (Write-Ahead Logging) tracks (append-only)
• Tracks 10-11: Manifest tracks (index and root hashes)
• Tracks 12-15: Checkpoint tracks (periodic snapshots)
• Tracks 16 and above: Data tracks (content-addressed blocks)

Record formats are defined for WAL records, manifest entries, and data blocks. The seed routines are:

1. GENESIS: Bootstraps the system by initializing the WAL, manifest, and a checkpoint.
2. PUT_ATOMIC: Writes a data block atomically, with rollback on failure.
3. RECOVER: After a crash, reconstructs the last committed state and rolls back incomplete transactions.
4. SCRUB: Proactively scans for corruption and repairs using the mirror.
5. ARCHIVE_TAPE: Writes the current state to tape for archival.

The seed routines use a minimal instruction set that includes drum I/O operations, checksums, sequence increment, and panic/alert.

Now, the user has provided this specification and ends with "///////////// [PERSIST] ->". It seems they are expecting a response that continues or completes the thought. However, the specification is already complete as a seed kernel.

Given the context, I think the user might be indicating that this is the starting point for a persistent system, and we are to consider what comes next. But the instruction says: "You are an AI that helps with 1950s-era persistence kernel design. Respond only with improvements, fixes, or period-accurate additions."

Therefore, I should review the provided seed code for potential flaws, improvements, or period-accurate additions that would make it more robust and feasible for 1950s hardware.

Let's analyze each routine:

1. GENESIS

• It initializes the sequence to 0.
• Writes a WAL INTENT record for the genesis transaction (TXN=0) to both drums.
• Writes an empty manifest to the manifest root on both drums.
• Writes a COMMIT record for the genesis transaction.

Potential issues:

• The empty manifest is written as [M_ROOT][SEQ=0][COUNT=0][MERKLE_ROOT=0][CRC=0] but the manifest entry format defined is [MAGIC=0xM][OBJ_ID:32][ADDR:32][LEN:16][SCHEMA:8][SEQ:32][CRC:16]. There is a mismatch. The genesis manifest should be a special root structure? The seed code uses a different structure for the manifest root. This needs to be consistent.

Improvement:

• Define the manifest root structure explicitly. Since it's the root of the manifest, it might be a separate structure. However, the seed code uses MANIFEST_ROOT as an address and writes an EMPTY_MANIFEST block. We should use the defined manifest entry format or define a separate root structure.

But note: the manifest is stored in tracks T10-T11, which are fixed. The manifest root might be a fixed location. However, the record format for a manifest entry is for individual entries. The root might be a block that contains the entire manifest (or a pointer to a tree). Since this is a seed, we can assume a flat manifest for simplicity.

However, the seed code writes EMPTY_MANIFEST as [M_ROOT][...] but the magic for manifest entries is 0xM. We should use the same magic. Also, the empty manifest should be a valid manifest block.

Let me redefine the empty manifest to fit the manifest entry format? But the manifest root might be a separate structure. Alternatively, the manifest root could be a block that contains multiple entries. Since the seed is minimal, we can have the manifest root block contain a header and then entries.

Given the constraints of 1950s hardware, we want simplicity. Let's change the manifest root to be a single block that has:

• Magic (0xM)
• Count of entries (0 for empty)
• An array of manifest entries (empty initially)
• CRC

But the defined MAN_ENTRY format is for individual entries. We need a container.

Alternatively, the manifest might be stored as a linked list of blocks? But the seed reserves two tracks (T10-T11) for the entire manifest. We can have the manifest root block at a fixed address (say T10, sector 0) that points to the first block of the manifest, but that complicates.

For the seed, let's keep it simple: the manifest root block is a fixed-size block at a fixed address (T10, sector 0) that contains:

1
2
MANIFEST_ROOT_BLOCK :=
  [MAGIC=0xM_ROOT] [SEQ:32] [ENTRY_COUNT:16] [ENTRIES: array of MAN_ENTRY of size ENTRY_COUNT] [CRC:16]

But the seed code uses [M_ROOT] which is not defined. We should define it.

Given the time period, we can avoid complex structures. Since the seed is minimal, we can have the manifest as a single block (until it grows, then we would need to extend, but that's beyond seed). So for genesis, we write an empty manifest block at the fixed manifest root address.

I propose to change the manifest root block format to:

1
2
MANIFEST_ROOT :=
  [MAGIC=0xM] [TYPE=0] (0 for root) [SEQ:32] [COUNT:16] [ENTRIES: variable] [CRC:16]

But the seed code writes [M_ROOT] which might be a typo. Let's use the same magic 0xM and a type field? Or just have the manifest root be a special address and the block format as defined for MAN_ENTRY? That doesn't fit.

Alternatively, the manifest root is not stored as a MAN_ENTRY but as a separate structure. We should define it.

Given the constraints, I think the seed intended the manifest root to be a fixed block that contains the entire manifest. So let's redefine:

Revised Manifest Root Block (for T10 sector 0):

1
2
MANIFEST_ROOT_BLOCK :=
  [MAGIC=0xM_ROOT] (or 0xMR) [SEQ:32] [COUNT:16] [ENTRIES: array of fixed-size MAN_ENTRY] [CRC:16]

But the size of the block is fixed by the drum sector size. We can have a fixed number of entries per block? But the seed is minimal.

Alternatively, the manifest is stored as a linked list of blocks, but that complicates the seed.

Given the time, I think the seed code has an inconsistency. We should fix it by defining the manifest root block format.

But the seed code says: EMPTY_MANIFEST ← [M_ROOT][SEQ=0][COUNT=0][MERKLE_ROOT=0][CRC=0]. This does not match the MAN_ENTRY format. We must have a consistent format.

Since the seed is minimal and we are in 1950, we can avoid Merkle trees initially. Let's drop the Merkle root for now and have a simple array.

I propose for the seed:

• The manifest root block (at fixed address MANIFEST_ROOT) has:
  • Magic: 0xMR (distinct from 0xM for entries)
  • SEQ:32
  • COUNT:16 (number of entries)
  • An array of fixed-size entries (each of size, say, 16 words? but we don't know word size) but we don't have variable length.

Alternatively, the manifest is stored as a series of MAN_ENTRY records appended in the manifest tracks. The manifest root block then just points to the latest manifest block? But the seed reserves two tracks for the entire manifest.

Given the complexity and period constraints, I think the seed intended a flat manifest in a single block. We'll assume the block size is large enough for a few entries (and when it fills, we would need to extend, but that's beyond seed).

So let's define the manifest root block as:

1
2
MANIFEST_ROOT_BLOCK :=
  [MAGIC=0xMR] [SEQ:32] [COUNT:16] [ENTRIES: COUNT * MAN_ENTRY_SIZE] [CRC:16]

But the MAN_ENTRY format is 32+32+16+8+32+16 = 136 bits? which might not be word-aligned.

Given the constraints, we might have to adjust. However, the seed code is pseudo-code. We can note the inconsistency and fix it by having the manifest root block have a header and then entries.

But to keep it simple and period-accurate, let's change the genesis to write a manifest root block that is a single MAN_ENTRY for the root? That doesn't work.

Alternatively, the manifest root is a special block that is not in the MAN_ENTRY format. We'll keep the seed as is but fix the magic and structure.

I think the best is to define a separate structure for the manifest root. Since the seed code uses [M_ROOT], we can define:

1
2
MANIFEST_ROOT_STRUCT :=
  [MAGIC=0xMR] [SEQ:32] [COUNT:16] [MERKLE_ROOT:32] [CRC:16]

But the seed writes [M_ROOT][SEQ=0][COUNT=0][MERKLE_ROOT=0][CRC=0] — so 1 word for magic, 1 for SEQ, 1 for COUNT, 1 for MERKLE_ROOT, 1 for CRC? That's 5 words.

We can do that. Then the manifest entries are stored separately? But the manifest tracks are for the entire index. The seed doesn't specify how the manifest is stored beyond the root.

Given the time, I think we should not change the seed drastically. Instead, note that the manifest root block format is different and acceptable for the seed.

But in the PUT_ATOMIC routine, it says APPEND_MANIFEST(MAN_ENTRY) which implies the manifest is append-only and grows. So the manifest root block must be updated to point to the new manifest? Or the manifest is stored as a log in the manifest tracks.

This is a flaw in the seed specification.

2. PUT_ATOMIC

• It uses MAP_TO_DATA_TRACKS(OBJ_ID) to choose an address. How is this mapping done? The seed doesn't specify. In 1950, we might use a simple hash modulo the number of data sectors.
• It reads the old value for rollback. But what if there is no old value? (first write to that address). The seed doesn't handle that. We should check if the old block is valid (by checking magic and CRC) or treat as zero.
• The rollback section writes the old value back. But if there was no old value (i.e., the block was free), then we should erase the new value? But the seed writes the old block which might be garbage.

Improvement:

• Check if the old block has valid magic and CRC. If not, then on rollback, we should write a zero block or mark as free? But the system doesn't have a free list in the seed.

Given the seed is minimal, we can assume that the data tracks are pre-initialized to zeros or a known pattern. Then, if the old block doesn't have valid magic, we treat it as empty.

But the seed doesn't specify initialization of data tracks.

3. RECOVER

• It scans the WAL from the last checkpoint. But how is the last checkpoint found? The seed doesn't specify a fixed location for the last checkpoint marker.
• It uses BLOCKLEN_AT_ADDR(ADDR) — how is the block length known? The data block has a LEN field, but to read the block we need to know the length to read. Chicken-and-egg.

In the data block format, the LEN field is after the magic and type. So we can read a fixed header first (e.g., the first two words) to get the LEN, then read the rest. But the seed doesn't specify.

4. SCRUB

• It iterates over DATA_TRACKS. How are the data blocks delimited? The drum is divided into sectors. We assume fixed-size sectors? Or variable-length blocks? The seed doesn't specify.

The data block format has a LEN field, so blocks are variable-length. But on drum, we need to know where one block ends and the next begins. The seed doesn't specify a block directory.

This is a flaw: without a directory, SCRUB cannot iterate over blocks.

5. ARCHIVE_TAPE

• It writes the manifest and checkpoints to tape. But the manifest is stored in the manifest tracks, which might be multiple blocks. The seed reads the manifest root block, but not the entire manifest.

The seed writes MAN ← DRUM_READ(DRUM_A, MANIFEST_ROOT, LEN_MANIFEST()) — but the manifest might be larger than one block.

Given the seed is minimal, we assume the manifest fits in one block initially.

Period-Accurate Additions and Fixes

Considering 1950s hardware constraints (slow, unreliable, word-oriented), we should:

1. Simplify structures: Use fixed-size records where possible to avoid variable-length parsing.
2. Robustness: Add more checksums and verification steps given the high error rate of drums.
3. Performance: Minimize seeks and rotations. For example, WAL append should be in a circular buffer to avoid long seeks.
4. Atomicity: The seed uses double-commit (WAL then data then commit). But on drum, a full rotation might be required for fsync. We should batch operations if possible, but the seed is minimal.

Proposed Fixes and Improvements

For GENESIS:

• Define the manifest root block format explicitly. Let's use:

  1
  2
  3
  4
  5
  MANIFEST_ROOT_BLOCK =
    [MAGIC_WORD = 0xMR]
    [SEQ: 1 word]
    [COUNT: 1 word]  // number of entries in this block
    [ENTRIES: array of fixed-size entries, each 8 words? but we don't know]
  

  But to keep it simple and since it's seed, we can have the manifest root block contain only a header and no entries initially. The entries are stored in subsequent sectors of the manifest tracks.
  However, the seed reserves two tracks for manifest. We can have the first sector (T10, sector0) as the manifest root header, and then the rest of the sectors in T10-T11 as a log of manifest entries.
  Change the genesis to write:
  • A manifest root header block at T10 sector0: [MAGIC=0xMR][SEQ=0][HEAD_PTR=0][TAIL_PTR=0][CRC] where HEAD_PTR and TAIL_PTR are pointers to the first and last manifest entry block (initially 0).
  • But that complicates.

Given the time period, I think the seed intended a flat, in-memory manifest that is written as a whole. Since memory is limited, we can assume the manifest is small.

We will keep the seed as is but change the empty manifest to a valid block that matches a defined structure. Let's define:

1
2
3
4
5
MANIFEST_ROOT_BLOCK =
  [MAGIC = 0xMR]  // 1 word
  [SEQ = 0]       // 1 word
  [COUNT = 0]     // 1 word
  [CRC = 0]       // 1 word (initially 0, then computed)

Then, when appending a manifest entry, we would read the entire manifest root block, add the entry, and write it back. But that is not scalable, but for seed it's acceptable.

In PUT_ATOMIC, the APPEND_MANIFEST routine would then be:

1
2
3
4
5
6
7
8
9
10
11
ROUTINE APPEND_MANIFEST(ENTRY):
  MAN_BLOCK = DRUM_READ(DRUM_A, MANIFEST_ROOT_ADDR, BLOCK_SIZE)
  IF MAN_BLOCK.COUNT >= MAX_ENTRIES:
      PANIC(MANIFEST_FULL)
  ELSE:
      MAN_BLOCK.ENTRIES[MAN_BLOCK.COUNT] = ENTRY
      MAN_BLOCK.COUNT = MAN_BLOCK.COUNT + 1
      MAN_BLOCK.SEQ = INC_SEQ()
      MAN_BLOCK.CRC = XOR_CHECKSUM(MAN_BLOCK without CRC)
      // Write new manifest block to both drums
      ...

But this is not atomic and not in the WAL. The seed code says APPEND_MANIFEST uses WAL+commit internally. We should do it properly.

Given the complexity, and since this is seed, we might skip manifest updates in the atomic write and do them later? But that breaks atomicity.

Alternatively, the manifest is updated via the same WAL mechanism. So the manifest update should be a separate transaction. But then the data write and manifest update are not atomic together.

The seed has a flaw: the manifest update is not atomic with the data write. If the system crashes after step 8 (updating manifest) but before step 9 (commit), then the data is written but the manifest is not updated, so the data is orphaned.

To fix, the manifest update should be part of the same transaction. But the seed does it after writing the data and before the commit marker.

Actually, the commit marker in step 9 is for the data write transaction. The manifest update is a separate transaction? The seed increments the sequence again for the manifest (MAN_SEQ ← INC_SEQ()).

This is a flaw. The entire operation (data write and manifest update) should be one transaction.

But the seed is minimal and for 1950, we might accept that the manifest is updated after the data is committed, and if the system crashes, the data is committed but not in the manifest, so it's leaked until the next scrub or rebuild.

The RECOVER routine has REBUILD_MANIFEST_FROM_WAL() which can rebuild the manifest from the WAL, so it's recoverable.

So it's acceptable for the seed.

For RECOVER:

• To find the last checkpoint marker, we can store a fixed "checkpoint head" block in a known location (e.g., in the manifest tracks) that points to the latest checkpoint. But the seed doesn't have that.
  Instead, we can scan the WAL from the end backwards until we find a CHECKPOINT_MARK record. But the WAL is append-only and might wrap around. The seed doesn't specify WAL rotation.
  Given the seed is minimal, we can assume the WAL is small and we scan from the beginning. But that is inefficient.
  We can store the address of the last checkpoint marker in a fixed location (e.g., in the manifest root block). But the seed doesn't have that.
  For now, we'll keep the seed as is and note that FIND_LAST_CHECKPOINT_MARKER_OR_START is implemented by scanning from the start.
• For BLOCKLEN_AT_ADDR(ADDR): we can read the first few words of the block to get the magic and length. But we must ensure the block is aligned and the header is readable even if the rest is corrupt.
  We can define that every block starts with a header that includes the length. For data blocks, the header is [MAGIC=0xD][TYPE:8][SCHEMA:8][SEQ:32][LEN:16] — that's 1 word for magic and type/schema? Let's assume a word is 32 bits.
  Suppose a word is 32 bits:
  • MAGIC: 8 bits, TYPE: 8 bits, SCHEMA: 8 bits, then 8 bits unused? Or we pack differently.

  The seed doesn't specify word size. We must assume a word size. Let's assume 32-bit words.

  Then the data block header might be:

  • Word0: MAGIC (8 bits) | TYPE (8 bits) | SCHEMA (8 bits) | UNUSED (8 bits)
  • Word1: SEQ (32 bits)
  • Word2: LEN (16 bits) | UNUSED (16 bits)
  • Then payload of LEN words
  • Then CRC (16 bits) in the last word? or a separate word.

  This is messy.

  Given the period, we can use fixed-size blocks. But the seed has variable-length payload.

  Alternatively, the drum sectors are fixed size (e.g., 32 words per sector). Then every block occupies one or more whole sectors. The LEN field indicates the number of words in the payload, but the block always takes full sectors.

  This simplifies addressing and scrubbing.

  I propose for period-accuracy: fixed-size sectors. Let's assume each drum sector is 32 words. Then every block is one sector. The LEN field in the block header indicates the used words within the sector.

  Then BLOCKLEN_AT_ADDR is always 32 words (the sector size).

  This is feasible in 1950 and simplifies the design.

For SCRUB:

• With fixed-size sectors, we can iterate by sector address.

For ARCHIVE_TAPE:

• With fixed-size manifest root block, we can read it entirely.

Summary of Proposed Changes

1. Assume fixed-size sectors for the drum. Let sector size = S words (e.g., 32 words). Every block (WAL record, manifest entry, data block) is stored in one or more whole sectors. For simplicity in the seed, we can assume that most blocks fit in one sector.
2. Redefine block formats to fit within a sector. For example:
   • WAL record: if the payload is too big, split across sectors? But seed can assume small payloads.
   • Data block: the payload LEN must be <= (sector_size - header_size - footer_size).
3. Manifest root block: define it as a fixed-size block at a fixed address (T10, sector 0). Format:

   1
   2
   3
   4
   5
   Word0: MAGIC = 0xMR (or 0x524D in ASCII? but numeric is fine)
   Word1: SEQ
   Word2: COUNT (number of entries)
   Word3 to Word30: array of MAN_ENTRY (each MAN_ENTRY is 4 words? to fit)
   Word31: CRC
   

   But we don't have space for many entries. Alternatively, the manifest root block contains only the header and pointers to chained blocks. But for seed, we assume COUNT=0 initially and only a few entries.
   We can change the MAN_ENTRY format to be more compact. For example, 32-bit fields might be overkill. In 1950, addresses might be 16-bit.
   Given the constraints, we should design for small drums.
4. RECOVER: change to use fixed sector size. To find the last checkpoint, scan the WAL tracks sector by sector from the beginning, and remember the last CHECKPOINT_MARK record.
5. PUT_ATOMIC: when reading the old block, check the magic and CRC. If invalid, treat as empty (all zeros). On rollback, if the old block was invalid, write a zeros block or a special "free" block.
6. GENESIS: write the manifest root block with the defined format.

Given the complexity and the fact that this is seed code, I will provide a revised version of the routines with these improvements, focusing on period-feasible fixes.

However, the user's request is to respond only with improvements, fixes, or period-accurate additions. So I should not rewrite the entire seed, but point out critical flaws and suggest minimal fixes.

Given the format, I think the most critical issues are:

• Manifest root block format: define it explicitly and make it consistent.
• Block length during recovery and scrub: assume fixed-size sectors to avoid variable-length parsing.
• Rollback for non-existent old block: handle the case where there is no valid old block.

Response Structure

I will provide a set of fixes and improvements in a concise manner.

We are given a Rust implementation of a seed persistence system for DAEMONO. The code is functional and demonstrates the core concepts: object store, WAL, manifest, and time totems. However, the problem statement requires a 1950-feasible pseudo-assembly / protocol spec. We must translate the Rust code into a low-level, period-appropriate specification.

Key constraints for 1950:

• No complex data structures (like dynamic vectors) in hardware.
• Fixed-size records and sectors.
• Bit-serial I/O and drum storage (with tracks and sectors).
• Limited arithmetic (no hardware multiply, let alone SHA256).
• Checksums are simple (XOR, parity, or basic CRC).
• No modern filesystems; raw block I/O.

We are to produce a minimal executable persistence kernel for the PERSISTOR/DAEMONO (1950) machine.

Given the seed code in Rust, we must map it to the 1950 pseudo-assembly format described in the initial problem statement.

Steps:

1. Data Types and Record Formats: We must define fixed-size records that fit in drum sectors. We replace SHA256 with a 1950-feasible checksum (like 16-bit XOR or simple CRC). We also replace variable-length fields with fixed-length or length-prefixed fields that fit in a sector.
2. Object Store: Instead of a filesystem with store/objects/<sha256>, we have fixed DATA tracks (T16..) on two mirrored drums. We use content-addressing but with a simple hash (e.g., 16-bit) and a fixed mapping from hash to track/sector.
3. WAL: We have dedicated WAL tracks (T0..T9). Each WAL record must fit in one sector. We use a simple CRC (16-bit) and fixed fields.
4. Manifest: We have fixed MANIFEST tracks (T10..T11). The manifest is stored as a fixed-size array of entries, each fitting in a sector.
5. Time Totem: We replace the Merkle tree with a simple checksum of the entire manifest and WAL range. The totem is stored in CHECKPOINT tracks (T12..T15).
6. Genesis Capsule: We store the initial state in the manifest and WAL as described in the initial seed routines (GENESIS).

We are to write the seed routines: GENESIS, PUT_ATOMIC, RECOVER, SCRUB, ARCHIVE_TAPE in the 1950 pseudo-assembly.

We must adhere to the initial problem's layout and record formats, but we can adjust for feasibility (e.g., fixed sector sizes, simple checksums).

Let's redefine the record formats for 1950:

• Sector Size: Assume 32 words of 16 bits each (typical for early drums). Total 512 bits per sector.
• Checksum: 16-bit XOR of all words in the sector (excluding the checksum word itself). Or a simple CRC-16 (feasible with shift registers).

We'll define:

1. WAL Record (fits in one sector):
   • [MAGIC: 16 bits] = 0x5741 ("WA")
   • [TYPE: 4 bits] (as before)
   • [SEQ: 32 bits] (logical clock)
   • [TXN: 32 bits] (transaction ID)
   • [ADDR: 32 bits] (address on drum: track, sector, offset)
   • [LEN: 16 bits] (payload length in words, max 16 words to fit in sector)
   • [PAYLOAD: variable] (up to 16 words = 256 bits)
   • [CRC: 16 bits] (checksum of the entire record except CRC)

   Note: The entire record must fit in 32 words. We have 1 (magic) + 0.25 (type, packed) + 2 (seq: 32 bits = 2 words) + 2 (txn) + 2 (addr) + 1 (len) + 16 (payload max) + 1 (crc) = 24.25 words -> we can fit if we pack type into a word with other flags.

   Alternatively, we can use a fixed layout with 32-bit words:

   Word 0: MAGIC (16 bits) | TYPE (4 bits) | RESERVED (12 bits) -> but we have 16-bit words.

   Let's redefine in 16-bit words:

   • Word 0: MAGIC (0x57 for first byte, 0x41 for second) -> two bytes, so two words? Actually, we can store MAGIC in one word: 0x5741.
   • Word 1: TYPE (4 bits) and then 12 bits reserved? Or use the next words for the rest.

   We must design for 16-bit words.

   Proposed WAL record (16-bit words):

   • Word 0: MAGIC (0x5741)
   • Word 1: TYPE (4 bits) | SEQ_HIGH (12 bits) -> but 32-bit SEQ needs two words. Instead, let's use:
   • Word 0: MAGIC (0x5741)
   • Word 1: TYPE (4 bits) and then 12 bits of flags? Not enough.

   Given the constraints, we might have to use multiple sectors for large records, but the seed requires atomicity. So we design for small payloads.

   We can do:

   • Word 0: MAGIC (0x5741)
   • Word 1: TYPE (4 bits) | (12 bits unused) -> but we need 32-bit SEQ.

   Alternatively, we can have a header of 8 words:

   • Word 0: MAGIC (0x5741)
   • Word 1: TYPE (4 bits) and then 12 bits of something else? Let's break down:

   We have 32 words per sector.

   Let's allocate:

   • Word 0: MAGIC (16 bits) -> 0x5741
   • Word 1: TYPE (4 bits) | SEQ[31:16] (12 bits) -> but 12 bits is not enough for half of SEQ. This is problematic.

   We must use multiple words for 32-bit fields.

   Revised:

   • Word 0: MAGIC (16 bits) -> 0x5741
   • Word 1: TYPE (4 bits) | RESERVED (12 bits) [we can use reserved for future]
   • Word 2-3: SEQ (32 bits) -> two words: [31:16] and [15:0]
   • Word 4-5: TXN (32 bits)
   • Word 6-7: ADDR (32 bits) -> track (8 bits), sector (8 bits), offset (16 bits) but we can pack into 32 bits.
   • Word 8: LEN (16 bits) -> number of words in payload (max 23 words because we have 9 words used so far, and one for CRC -> 32-10=22 words for payload?).

   Actually, 32 words total:

   • Words 0-8: 9 words for header
   • Words 9 to 30: 22 words for payload (max LEN=22)
   • Word 31: CRC (16 bits)

   So:

   1
   2
   Word 0: 0x5741
   Word 1: (TYPE << 12) | (RESERVED & 0x0FFF)  [but we don't have 12 bits of reserved? Actually, we can use the whole word for TYPE and flags?]
   

   Instead, let's put TYPE in the high 4 bits of word 1, and the rest 12 bits as reserved (or part of SEQ?).

   We can do:

   • Word 0: MAGIC
   • Word 1: TYPE (4 bits) in the high nibble, and the low 12 bits as the high 12 bits of SEQ? But SEQ is 32 bits.

   This is getting messy.

   Given the era, it's acceptable to have fixed record sizes and not pack bits too tightly. We can use:

   • Word 0: MAGIC (0x5741)
   • Word 1: TYPE (as a whole word, 16 bits) -> but we only need 4 bits. We can use 0x0001, 0x0002, etc.
   • Word 2-3: SEQ (two words for 32 bits)
   • Word 4-5: TXN (two words)
   • Word 6-7: ADDR (two words: track in high 8 bits of word6, sector in low 8 bits of word6 and high 8 of word7? Not straightforward)

   Alternatively, we can define ADDR as a 32-bit value: (track << 24) | (sector << 16) | offset. Then two words for 32 bits.

   So:

   • Word 0: MAGIC (0x5741)
   • Word 1: TYPE (16 bits) -> values 1,2,3,4,5
   • Word 2: SEQ high (16 bits)
   • Word 3: SEQ low (16 bits)
   • Word 4: TXN high
   • Word 5: TXN low
   • Word 6: ADDR high
   • Word 7: ADDR low
   • Word 8: LEN (16 bits) -> number of payload words
   • Words 9 to 9+LEN-1: payload
   • Word 31: CRC

   But then the payload can be at most 22 words (because 9 header words + 1 CRC word = 10, leaving 22).

   This is acceptable.

   CRC is computed over words 0 to 30 (excluding the CRC word).

2. Manifest Entry (fits in one sector):
   We have fixed MANIFEST tracks. Each entry:
   • [MAGIC=0x4D4E ("MN")] (16 bits)
   • [OBJ_ID: 16 bits] (we use 16-bit hash for 1950)
   • [ADDR: 32 bits] (two words)
   • [LEN: 16 bits] (one word, number of words in the object)
   • [SCHEMA: 8 bits] (one byte, so in one word we can have schema in high byte and reserved in low)
   • [SEQ: 32 bits] (two words)
   • [CRC: 16 bits] (one word)

   Total words: 1 (magic) + 1 (obj_id) + 2 (addr) + 1 (len) + 1 (schema+reserved) + 2 (seq) + 1 (crc) = 9 words. We can put multiple entries per sector? Or one entry per sector for simplicity.

   Since we have 32 words per sector, we can store 3 entries per sector (9*3=27, plus 5 words for sector header?).

   But for simplicity in the seed, we do one entry per sector.

   So:

   • Word 0: MAGIC (0x4D4E)
   • Word 1: OBJ_ID (16 bits)
   • Word 2-3: ADDR (32 bits)
   • Word 4: LEN (16 bits)
   • Word 5: SCHEMA (8 bits in high byte, 0 in low byte) -> or just use the whole word for schema ID (16 bits)
   • Word 6-7: SEQ (32 bits)
   • Word 8: CRC (16 bits) -> checksum of words 0-7

   The rest of the sector is unused (or used for future expansion).

3. Data Block:
   • [MAGIC=0x4441 ("DA")] (16 bits)
   • [TYPE: 8 bits] (in a word, high byte)
   • [SCHEMA: 8 bits] (low byte of the same word? Or next word)
   • [SEQ: 32 bits] (two words)
   • [LEN: 16 bits] (one word, number of words in payload)
   • [PAYLOAD: variable] (up to 25 words? because header is 5 words + CRC = 6, so 26 words for payload? 32-6=26)
   • [CRC: 16 bits] (one word)

   Header:

   • Word 0: MAGIC (0x4441)
   • Word 1: (TYPE << 8) | SCHEMA
   • Word 2-3: SEQ
   • Word 4: LEN
   • Words 5 to 5+LEN-1: payload
   • Word 31: CRC

   So max LEN = 26.

4. Time Totem (for checkpoint):
   We store in CHECKPOINT tracks. One sector per totem.
   • [MAGIC=0x5454 ("TT")]
   • [EPOCH: 32 bits] (two words)
   • [PREV_TOTEM: 16 bits] (16-bit hash of previous totem)
   • [WAL_SEQ_MIN: 32 bits] (two words)
   • [WAL_SEQ_MAX: 32 bits] (two words)
   • [EVENTS_ROOT: 16 bits] (16-bit hash of WAL events in this epoch)
   • [ARTIFACTS_ROOT: 16 bits] (16-bit hash of manifest entries)
   • [MANIFEST_ID: 16 bits] (16-bit hash of manifest)
   • [COMMIT_HASH: 16 bits] (hash of the totem without this field)

   Total: 1 + 2 + 1 + 2 + 2 + 1 + 1 + 1 + 1 = 12 words. We can fit.

   CRC for the entire totem sector.

Given these constraints, we now write the seed routines in pseudo-assembly.

We assume the machine services from the initial problem:

• DRUM_READ(drum, addr, len) -> buffer
• DRUM_WRITE(drum, addr, buffer, len)
• DRUM_APPEND(drum, WAL_TRACKS, record) -> wal_addr (appends to WAL, returns address)
• DRUM_FSYNC(drum) (wait full rotation + verify readback)
• DRUM_VERIFY(drum, addr) -> ok/fail
• CMP(buf1, buf2) -> equal?
• XOR_CHECKSUM(buf) -> crc16 (16-bit)
• INC_SEQ() -> seq
• PANIC(code)
• TAPE_WRITE(block), etc.

We also assume a simple allocator for DATA tracks: MAP_TO_DATA_TRACKS(hash) -> addr (using a fixed mapping: hash modulo number of data sectors).

Now, we write the routines.

Note: We use 16-bit words throughout.

Let's start with GENESIS:

GENESIS:

Goal: establish first durable anchors.

Steps:

1. Initialize logical time to 0.
2. Write GENESIS record to WAL on both drums (INTENT type).
3. Initialize MANIFEST_ROOT on both drums (empty manifest: one sector with magic and zeros).
4. Commit GENESIS (COMMIT type).

We define the empty manifest as:

• Word 0: MAGIC (0x4D4E for manifest? But we have a manifest root sector) -> let's use 0x4D52 ("MR") for manifest root.
• Word 1: COUNT (number of entries) = 0
• Word 2: CRC (checksum of words 0 and 1)

But we have 32 words. We can do:

• Word 0: MAGIC (0x4D52)
• Word 1: COUNT (16 bits) = 0
• Word 2: ROOT_HASH (16 bits) = 0 (for empty)
• Word 3: CRC

Then the rest unused.

But for simplicity, we do one sector for the manifest root that points to the first manifest entry sector? Or the manifest is stored as a linked list.

Given the seed, we do a simple vector in contiguous sectors. The manifest root sector contains:

• [MAGIC=0x4D52]
• [SEQ:32]
• [COUNT:16]
• [FIRST_SECTOR_ADDR:32] (address of first manifest entry sector)
• [CRC:16]

But for genesis, COUNT=0, FIRST_SECTOR_ADDR=0.

We'll do:

MANIFEST_ROOT sector:

• Word 0: 0x4D52
• Word 1-2: SEQ (32 bits) = 0
• Word 3: COUNT (16 bits) = 0
• Word 4-5: FIRST_SECTOR_ADDR (32 bits) = 0
• Word 6: CRC (16 bits) of words 0-5

Now, GENESIS routine:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
ROUTINE GENESIS:
  SEQ ← 0
  TXN ← 0
  // Build GENESIS INTENT record for WAL
  // We'll have a payload that points to the manifest root address (which we will write next)
  // But for genesis, we can have empty payload.
  // We need to choose an address for the manifest root. Let's fix it: track T10, sector 0.
  MANIFEST_ROOT_ADDR_A ← (DRUM_A, T10, 0, 0)  // (drum, track, sector, offset=0)
  MANIFEST_ROOT_ADDR_B ← (DRUM_B, T10, 0, 0)
  // Build WAL record for INTENT
  // TYPE=0x1 (INTENT)
  // PAYLOAD: we can put the manifest root address? Or empty. Let's put a fixed payload: "GENESIS"
  PAYLOAD ← [0x47, 0x45, 0x4E, 0x45, 0x53, 0x49, 0x53]  // "GENESIS" in ASCII, but we have words -> 4 words? We can do 4 words of payload: "GENE", "SIS", and then zeros? But we have limited space.
  Instead, we do minimal payload: empty. LEN=0.
  So:
    MAGIC: 0x5741
    TYPE: 0x0001  (whole word)
    SEQ: 0 (words 2-3: 0,0)
    TXN: 0 (words 4-5: 0,0)
    ADDR: MANIFEST_ROOT_ADDR_A (packed into 32 bits: track=10, sector=0, offset=0 -> 0x000A0000) -> words 6-7: 0x000A, 0x0000
    LEN: 0 (word 8)
    PAYLOAD: none
    CRC: computed over words 0-30 (but we only have 9 words so far? We must fill the sector)
  We must fill the entire sector. We can set unused words to 0.
  Steps for WAL record:
    Buffer[0] = 0x5741
    Buffer[1] = 0x0001   // TYPE
    Buffer[2] = 0x0000   // SEQ high
    Buffer[3] = 0x0000   // SEQ low
    Buffer[4] = 0x0000   // TXN high
    Buffer[5] = 0x0000   // TXN low
    Buffer[6] = 0x000A   // ADDR high: track=10, sector=0 -> we pack: (track << 8) | sector = 0x0A00, but we have 32 bits. Let's define ADDR as 32 bits: (track << 16) | (sector << 8) | offset. Since offset=0, sector=0, track=10: 0x000A0000 -> high word=0x000A, low word=0x0000.
    Buffer[7] = 0x0000
    Buffer[8] = 0x0000   // LEN=0
    // Words 9 to 30: 0
    // Compute CRC over words 0 to 30 (31 words) -> but we have 32 words, last is CRC.
    CRC = XOR_CHECKSUM(Buffer[0..30])  // 31 words, 62 bytes? But our XOR_CHECKSUM works on words? We can do word-wise XOR.
    Actually, we can compute a 16-bit CRC that is the XOR of all words from 0 to 30.
    Buffer[31] = CRC
  Then append this record to WAL on both drums.
  But note: DRUM_APPEND will write to the next available sector in WAL tracks.
  We assume WAL tracks are managed as a circular buffer, but for genesis we start at the beginning.
  We write the record to DRUM_A and DRUM_B at the first WAL sector.
  Then FSYNC both drums.
  Then write the empty manifest root sector:
    Buffer[0] = 0x4D52   // "MR"
    Buffer[1] = 0x0000   // SEQ high
    Buffer[2] = 0x0000   // SEQ low
    Buffer[3] = 0x0000   // COUNT=0
    Buffer[4] = 0x0000   // FIRST_SECTOR_ADDR high (0)
    Buffer[5] = 0x0000   // low
    Buffer[6] = XOR_CHECKSUM(Buffer[0..5])  // words 0 to 5
    // rest 0
  Write to MANIFEST_ROOT_ADDR_A and MANIFEST_ROOT_ADDR_B.
  FSYNC both drums.
  Then write COMMIT record:
    TYPE=0x0002 (COMMIT)
    PAYLOAD: we can put the hash of the manifest root? But we have 16-bit hash. We can compute the CRC of the manifest root sector (excluding its CRC) as the hash.
    But for simplicity, payload empty.
    Similar to INTENT record but TYPE=2, and ADDR can be the WAL address of the INTENT record? Or the manifest root address.
    We'll put ADDR = MANIFEST_ROOT_ADDR_A.
    Build record:
      Buffer[0] = 0x5741
      Buffer[1] = 0x0002
      Buffer[2-3] = SEQ=0
      Buffer[4-5] = TXN=0
      Buffer[6-7] = MANIFEST_ROOT_ADDR_A (0x000A0000 -> high=0x000A, low=0x0000)
      Buffer[8] = 0   // LEN=0
      ... zeros ...
      Buffer[31] = CRC of words 0-30
    Append to WAL on both drums, FSYNC.
  Return OK.
This is a simplified genesis.
Given the complexity, we must be concise.
We'll write the routines in the style of the initial problem statement, but updated for the 1950 constraints and the Rust seed's intent.
Let's produce the full seed routines.